Multi-target net8.0 and net10.0 - #7

Adds build/verify_native_binary.sh, called from pack_runtime_package, so a
binary that fails inspection never becomes a package.

Checks per RID:

- architecture matches the RID. A mis-targeted binary produces a package
  that restores fine and never loads.
- every P/Invoke symbol is exported. The expected list is read from the
  EntryPoint attributes in NativeMethod.cs rather than kept in the script,
  so it cannot drift away from what the wrapper imports.
- no dependency outside a per-platform allowlist. This is the check that
  catches the libgcc_s_dw2-1.dll class of bug, where a binary links against
  a toolchain runtime that the package does not ship: it works on the
  machine that built it and fails everywhere else.
- Linux only, the highest required glibc symbol version stays within a
  declared floor. The floor decides which distributions can consume the
  packages and is a property of the build image, so it can rise silently
  when that image is bumped. Currently 2.34, which covers RHEL 9,
  Debian 12 and Ubuntu 22.04. linux-x86 sits exactly on it.

Verified against all eight RIDs, and against two deliberately bad inputs:
an x86-64 binary declared as linux-arm64, and a win-x86 built without
-static-libgcc, which is the bug this repository actually shipped. Both
are rejected.

Note that bug only reproduces with the mingw gcc 10 on jammy; the gcc 13
on noble does not emit the dependency at all. -static-libgcc stays so the
output does not depend on which compiler the base image happens to ship.

llvm is added to the build image because binutils cannot read aarch64 PE.

Co-Authored-By: Claude Opus 5 <[email protected]>

Two problems, both found by running the script from outside the
repository while verifying the 3.38.0 bump.

The symbol check passed against an empty list. expected_symbols read
NativeMethod.cs and was called through command substitution, so when the
file could not be read it printed an error, exited its own subshell, and
left the caller to compare against nothing. The output read "all 0
P/Invoke symbols exported", which looks like a pass and asserts nothing.
The list is now resolved once in the main shell, where a missing or
unparsable NativeMethod.cs stops the script.

find_tool only looked where Linux distributions put things, so on macOS
the ELF checks could not run at all: command -v nm finds BSD nm, which
has no -D. It now takes several interchangeable names in preference
order and also searches Homebrew's keg-only prefixes, so llvm-readelf,
llvm-nm and llvm-readobj are used when present. Those read ELF, PE and
Mach-O alike, so with brew install llvm all eight RIDs can be verified on
a Mac without a container.

Verified: all eight RIDs pass natively on macOS, and a script run where
NativeMethod.cs is unreachable now exits 1 instead of reporting success.

Co-Authored-By: Claude Opus 5 <[email protected]>

LibLouis.NET and the test project build for both.

The extensions packages are referenced per target framework, 8.0.2 for
net8.0 and 10.0.10 for net10.0, so a net10.0 consumer does not drag an
older set into its dependency graph. The runtime packages stay on
netstandard2.0: they carry no managed code, and netstandard2.0 is the
widest thing to be compatible with. Microsoft.NET.Test.Sdk moves to
18.8.1, the first version that supports net10.0.

Packing a multi-targeted project runs the cross-targeting outer build,
which has no default None items, so the existing <None Update="LICENSE">
matched nothing there and the licence silently never reached the package
(NU5030). The inner builds do have the item, where a second Include would
be a duplicate, so both forms are present and conditioned on whether
TargetFramework is set.

The container's own SDK version is deliberately not touched here. It
compiles C and runs dotnet pack, and which SDK does the packing barely
affects the output; moving it belongs with the Dockerfile restructure
that separates compiling from packing, not with the multi-targeting.

Verified: both target frameworks build and pass, and the package carries
lib/net8.0 and lib/net10.0 with matching per-TFM dependency groups.

Co-Authored-By: Claude Opus 5 <[email protected]>